home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0399 / 293 < prev    next >
Internet Message Format  |  1994-08-27  |  3KB
  1. Date: Mon, 7 Jun 93 09:28:02 -0400
  2. From: "Nicholas S Castellano" <entropy@terminator.rs.itd.umich.edu>
  3. To: shenson@nyx.cs.du.edu
  4. In-Reply-To: Stephen Henson's message of Sun, 6 Jun 93 09:12:08 MDT <9306061512.AA28426@nyx.cs.du.edu>
  5. Subject: PL5 in progress ...
  6.  
  7. >1. Using a method analagous to that used by tfork() I've managed to get minixfs
  8. >to spawn an update daemon as part of its initialisation (without needing a
  9. >separate program). Is this legitimate ? Particularly, I'm thinking about memory
  10. >protection since the new process ends up in user mode sharing the memory of
  11. >minix.xfs itself. I prefer this method rather than a separate program because
  12. >it's all self contained and can make use of some minixfs info not normally
  13. >available to a separate process.
  14.  
  15. I can't say anything about the legitimacy of your method; that's
  16. Eric's department.  I can say how I'd like to see this handled, since
  17. I've given it a little bit of thought but haven't sent any of them to
  18. the list until now, since I haven't done any MiNT filesystem work and
  19. figured there'd be obvious problems with it.  Feel free to rip this
  20. idea apart...
  21.  
  22. What we need is a new system call, Fsync().  By default, this will
  23. point to an empty list of sync handlers.
  24.  
  25. In the kerinfo structure, filesystems should then get a pointer to a
  26. routine which will install a sync handler for it.  Minixfs and any
  27. other fs can call this routine once at startup.
  28.  
  29. The advantage of this method is that it will mean only one update
  30. daemon will be needed, to call Fsync() repeatedly, no matter how many
  31. filesystems are installed.
  32.  
  33. >2. Everything is fine when certain GEM stuff isn't running. When GEM stuff is
  34. >running the daemon hardly ever gets in. Presumably this is down to MiNT not
  35. >pre-empting GEM; does Multi-TOS fix this ? I suppose other users could always
  36. >have a small DA with an evnt_timer/Syield() loop in it.
  37.  
  38. My guess would be that the daemon would get some slices whenever the
  39. GEM program entered the Bios/Xbios/Gemdos (more uneducated guesses
  40. here...)  which are the only times it would really matter.  I guess it
  41. would be unfortunate if the sequence went: gem program makes Gemdos
  42. call, context switch to update daemon occurs, daemon does Fsync()
  43. [nothing happens since Gemdos calls hasn't done anything yet], context
  44. switch back to gem program's Gemdos call occurs, gemdos call
  45. completes, gem program continues and hogs the system again, preventing
  46. the update daemon from forcing the sync.  I'll leave it to the real
  47. gurus to figure out if this is the case.
  48.  
  49. Cheers,
  50. entropy
  51.